[SIP Beyond VoIP] Sylk does not use maddr in the 200 OK that is reply to NOTIFY request

[Record Route]

I must be the Contact then :)

On Thu, Jan 31, 2013 at 12:49 AM, Iñaki Baz Castillo <ibc at aliax.net> wrote:

> 2013/1/30 Iñaki Baz Castillo <ibc at aliax.net>:
> > 2013/1/30 Record Route <recordroute at gmail.com>:
> >> Sylk seems to be not using the maddr ip in the Contact header of 200OK,
> Then
> >> this results in, further NOTIFY messages are sent by Sylk to clients
> >> directly, not to my sip proxy.
> >>
> >> I guess, a fix needs to be applied, what should I do?
> >
> > Your SIP proxy should add a Record-Route to *every* NOTIFY request as
> > the RFC 3265 states:
> >
> > http://tools.ietf.org/html/rfc3265
> >
> > 3.2.3. Proxy NOTIFY Behavior
> >
> >    Proxies need no additional behavior beyond that described in SIP [1]
> >    to support NOTIFY.  If a proxy wishes to see all of the SUBSCRIBE and
> >    NOTIFY requests for a given dialog, it MUST record-route the initial
> >    SUBSCRIBE and any dialog-establishing NOTIFY requests.  Such proxies
> >    SHOULD also record-route all other SUBSCRIBE and NOTIFY requests.
> >
> >
> >
> > Using "maddr" is discouraged by RFC 3261 (which is 11 years old !!!):
> >
> >      The maddr field has been used as a simple form of loose source
> >      routing.  It allows a URI to specify a proxy that must be
> >      traversed en-route to the destination.  Continuing to use the
> >      maddr parameter this way is strongly discouraged (the
> >      mechanisms that enable it are deprecated).  Implementations
> >      should instead use the Route mechanism described in this
> >      document, establishing a pre-existing route set if necessary
> >      (see Section 8.1.1.1).  This provides a full URI to describe
> >      the node to be traversed.
>
>
> Summarizing: the solution is in the display-name of your mail address ;)
>
>
>
> --
> Iñaki Baz Castillo
> <ibc at aliax.net>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ag-projects.com/pipermail/sipbeyondvoip/attachments/20130131/ecbc9513/attachment-0001.html>