[Spce-user] Callee hangup doesnt' send BYE ...

[Sébastien Cramatte]

Hi,

We have opened an issue with our SIP trunk wholesale provider (Jazztel / 
Spain) and they told us that is the normal behavior ...
Their policy for land lines are to doesn't send  "BYE"  when callee 
hangup first ...

Do  you think that this behavior  is setup for any technical reason on 
their side ?
Do other SIP trunk providers in others countries do the same thing  ?

Thank you to light me


El 16/01/12 17:03, Andreas Granig escribió:
> Hi,
>
> Haven't seen it in your trace, maybe you can refine your filter to catch
> that as well and send it over again?
>
> Andreas
>
> On 01/16/2012 04:58 PM, Sébastien Cramatte wrote:
>> We have just seen that   BYE income on  kamailio-lb.log  ...
>> But is not relayed to ...
>>
>>
>> El 16/01/12 15:55, Andreas Granig escribió:
>>> Hi Sebastien,
>>>
>>> I don't see any BYE in the trace, which means your Peering Server (the
>>> Huawei?) is acting incorrectly.
>>>  From the (Record-)Route point of view it looks fine, otherweise the
>>> re-INVITE and the ACKs won't be routed correctly.
>>>
>>> Andreas
>>>
>>> On 01/16/2012 03:42 PM, Sébastien Cramatte wrote:
>>>> Hi Andreas,
>>>>
>>>> Please take a look to sp_trace attached file
>>>>
>>>> xx.xx.xx.xx =>   Sip Provider IP
>>>> yy.yy.yy.yy =>   Peering IP
>>>> zz.zz.zz.zz =>  Client IP
>>>>
>>>> 868xxxxxx =>   Caller number (SP subscriber)
>>>> 968xxxxxx =>   Callee number  (PSTN number)
>>>>
>>>> The scenario  was  sp subscriber calls callee and hang the callee !
>>>>
>>>> Thank you
>>>>
>>>> El 16/01/12 14:00, Andreas Granig escribió:
>>>>> Hi Sebastien,
>>>>>
>>>>> On 01/16/2012 01:26 PM, Sébastien Cramatte wrote:
>>>>>> We have got issue  with our SIP peering.
>>>>>> Callee hangup doesnt' send BYE.
>>>>>>
>>>>>> How can we solve this issue ?  Does it is related to SIP Provider ?
>>>>> If you hang up on the callee side and it doesn't send a BYE to the SP,
>>>>> then it's a client issue, where we can't do anything about it.
>>>>> If it sends a BYE, but it's not forwarded to the calling party, then
>>>>> please provide a full SIP trace for us to have a look. Maybe some Route
>>>>> headers sent by the callee are not ok.
>>>>>
>>>>> Andreas
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Spce-user mailing list
>>>>> Spce-user at lists.sipwise.com
>>>>> http://lists.sipwise.com/listinfo/spce-user
>>>>
>>>> _______________________________________________
>>>> Spce-user mailing list
>>>> Spce-user at lists.sipwise.com
>>>> http://lists.sipwise.com/listinfo/spce-user
>>>
>>> _______________________________________________
>>> Spce-user mailing list
>>> Spce-user at lists.sipwise.com
>>> http://lists.sipwise.com/listinfo/spce-user
>>
>>
>> _______________________________________________
>> Spce-user mailing list
>> Spce-user at lists.sipwise.com
>> http://lists.sipwise.com/listinfo/spce-user
>
>
> _______________________________________________
> Spce-user mailing list
> Spce-user at lists.sipwise.com
> http://lists.sipwise.com/listinfo/spce-user

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sipwise.com/pipermail/spce-user_lists.sipwise.com/attachments/20120117/97d9c21c/attachment-0001.html>