[SR-Users] t_relay dying ?

Jean CĂ©rien cerien.jean at gmail.com
Mon Jan 8 14:39:23 CET 2018


Thanks for this answer. The voip provider is not really eager to alter its
SBC as it considers that the contact field is not mandatory in the ACK. The
RFC states (section 8.1.1.8)

The Contact header field MUST be present and contain exactly one SIP
   or SIPS URI in any request that can result in the establishment of a
   dialog.  For the methods defined in this specification, that includes
   only the INVITE request


The ACK does not establish the dialog, no new call id / dialog id is being
generated.

I guess I need to implement the mechanism you've described, unless you
think they mis-interpret the RFC,

Regards
J.

On Thu, Jan 4, 2018 at 4:48 AM, Daniel-Constantin Mierla <miconda at gmail.com>
wrote:

> Hello,
>
> if one side of the call is breaking the contact, then a workaround in
> kamailio is to use htable to store the contact address per callid+from/to
> tag. I encountered couple of times such situation and the condition in the
> config file is like:
>
>   - if the r-uri of ACK (BYE, etc...) matches "myself", then check to see
> if there is a record in an htable corresponding to callid and to-tag, if
> yes, use it
>
> Contact for caller is set in htable as INVITE is received and for callee
> when then 200ok is received.
>
> If dialog module is used, then the contact from the dialog structure can
> be used. With 5.1 or newer, dialog offers a dedicated function for this:
>
>   - https://www.kamailio.org/docs/modules/stable/modules/dialog.
> html#dialog.f.dlg_set_ruri
>
> For older versions, the address has to be taken from $dlg(...) variable,
> with some conditions to detect if it is the caller or callee side.
>
> Cheers,
> Daniel
>
> On 03.01.18 16:16, Sebastian Damm wrote:
>
> Hi Jean,
>
> as pointed out earlier, the ACK is probably broken. Every packet after the
> 200 OK should have the contact of the 200 OK in the Request URI. Your
> example packet carries probably the original request URI, which is most
> certainly wrong, exept if you use some topology hiding.
>
> This is something you can't fix but the voip provider has to fix. They
> apparently can't handle proxied SIP connections.
>
> Regards,
> Sebastian
>
>
>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing Listsr-users at lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>
> --
> Daniel-Constantin Mierlawww.twitter.com/miconda -- www.linkedin.com/in/miconda
> Kamailio Advanced Training - www.asipto.com
> Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com
>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20180108/a7c3e51d/attachment.html>


More information about the sr-users mailing list