[Serusers] NOTIFY header construction for mid-dialog presence event package
Greger V. Teigre
greger at teigre.com
Wed Aug 15 13:20:29 CEST 2007
You can actually use the select and avps to implement Path header
functionality in ser.cfg by storing path info in db. I have never done
it, but a how-to for iptel.org faqs would be much appreciated ;-)
g-)
Vaclav Kubart wrote:
> On Po, srp 06, 2007 at 11:41:46 +0200, samuel wrote:
>
>> I'll give a try to this parameter...I didn't pay enough attention to the
>> serdev mail....
>>
>> Maybe a reasonable approach would be to be able to define a presence
>> outbound proxy (as it's done in presence_b2b) and you can set up "easily" a
>> separate presence proxy or route the messages to yourself so you can process
>> it again in your config script. This would, however, break just a little bit
>> 3261 routing algorithm....easy but I don't like it...
>>
>
> Good idea. :-) I like it much more than calling script routes from presence
> modules. And it is much easier to implement it.
>
> But similar effect could be probably got by forwarding the SUBSCRIBE
> request once more to itself if it will be needed to process the NOTIFYs
> by nathelper. (Adds a step to routes where can be the "deNATification"
> done.)
>
>
>> Thinking loud...what about Path or Service-Route headers compatibility in
>> presence modules?? Setting up these headers would allow flexible routing
>> while keeping compliancy to standards...Can this be achieved with
>> 2.0release and select framework??
>>
>
> Sorry, we don't support these in presence modules...
>
> Vaclav
>
>
>> Regards,
>>
>> Samuel.
>>
>> 2007/8/6, Vaclav Kubart <vaclav.kubart at iptel.org>:
>>
>>> Yes, you are right.
>>>
>>> But Maxim has introduced new module parameter by which you can say, that
>>> NOTIFY is not target refresh request and thus NOTIFY responses won't
>>> refresh the target.
>>>
>>> From my point of view is this only temporary hack (because NOTIFY was in
>>> some discussions aggreed to be target refresh). Better solution is
>>> probably to let the NOTIFY go through config script and process it and
>>> its responses by nathelper.
>>>
>>> Vaclav
>>>
>>> On Po, srp 06, 2007 at 10:24:17 +0200, samuel wrote:
>>>
>>>> mmmm
>>>>
>>>> coming back to the discussion....the missing OK Contact mangle happened
>>>>
>>> with
>>>
>>>> a separated prosence proxy...
>>>>
>>>> I was wondering...In the case of a single SIP server
>>>> (proxy,registrar,presence,...) when the "presence" part sends the NOTIFY
>>>>
>>> to
>>>
>>>> a natted UA and this latter one replies with the 200OK, the Contact
>>>>
>>> would
>>>
>>>> contain the internal IP and since this NOTIFY is not handled by the SER
>>>> route config file , it can not be managed by nathelper|mediaproxy
>>>>
>>> options.
>>>
>>>> This would cause a modification in the target of the dialog to the
>>>>
>>> internal
>>>
>>>> IP (following RFC 3261) and the presence dialog would be useless because
>>>>
>>> no
>>>
>>>> notifications would work....am I right?
>>>>
>>>> Thanks,
>>>> Samuel.
>>>>
>>>> 2007/8/3, samuel <samu60 at gmail.com>:
>>>>
>>>>> Ok.
>>>>>
>>>>> I found out the "problem", there was a missing NAT handling of the
>>>>> responses, and the 200 OK response updated the target dialog with a
>>>>> non-routable IP. That's why further messages had the wronf Req-URI.
>>>>>
>>>>> Thanks for your pointers,
>>>>> sam.
>>>>>
>>>>> 2007/8/2, Vaclav Kubart <vaclav.kubart at iptel.org>:
>>>>>
>>>>>> Hi Samuel,
>>>>>> Maxim Sobolev was fighting with NAT and presence some time ago.
>>>>>>
>>>>>> I was trying to allow calling script route block when sending NOTIFY
>>>>>>
>>> to
>>>
>>>>>> allow its modifications, but I had not enough time to get results.
>>>>>>
>>>>>> The NOTIFY should be constructed according RFC 3261; the request URI
>>>>>> should be the value from Contact of the SUBSCRIBE request (if only
>>>>>>
>>> loose
>>>
>>>>>> routers in routes appear).
>>>>>>
>>>>>> To, From, Via and routes should follow RFC 3261 too.
>>>>>>
>>>>>> Contact header value is the address at which the SUBSCRIBE request
>>>>>> arrives to the server (according examples in RFC 3856, this is
>>>>>> controversial but possible).
>>>>>>
>>>>>> Modifying of async_auth_queries should have no influence on sent
>>>>>> NOTIFYs. If does, it is probably a bug.
>>>>>>
>>>>>> All headers you mentioned are derived from dialog initiating
>>>>>>
>>> SUBSCRIBE
>>>
>>>>>> request as RFC says.
>>>>>>
>>>>>> Vaclav
>>>>>>
>>>>>> On Čt, srp 02, 2007 at 12:05:02 +0200, samuel wrote:
>>>>>>
>>>>>>> Hi all!!!
>>>>>>>
>>>>>>> I'm experiencing quite difficulties setting up a dedicated (and
>>>>>>>
>>>>>> separated)
>>>>>>
>>>>>>> presence server with NATted end-points and the dstblacklist
>>>>>>>
>>> feature.
>>>
>>>>>>> I'd like to get some info about the construction of the most
>>>>>>>
>>> important
>>>
>>>>>>> headers (Req-URI,Contact,To,From,Via,Routr) for the different
>>>>>>>
>>> NOTIFY
>>>
>>>>>>> modalities depending on the state of the subscription.
>>>>>>>
>>>>>>> Setting up async_auth_queries I've seen the pending and the active
>>>>>>>
>>>>>> NOTIFY
>>>>>>
>>>>>>> have different Req-URI and the second one is blocked by the NAT
>>>>>>>
>>>>>> router.
>>>>>>
>>>>>>> Further mid-dialog NOTIFYs providing changes in the presence
>>>>>>>
>>> status
>>>
>>>>>> has also
>>>>>>
>>>>>>> different headers...
>>>>>>> My main concern is whether the info for constructing the routing
>>>>>>>
>>>>>> headers is
>>>>>>
>>>>>>> taken from location table, from watcherinfo.dialog table, or from
>>>>>>>
>>> the
>>>
>>>>>>> incoming message...I know I could follow the code but an
>>>>>>>
>>> explanation
>>>
>>>>>> would
>>>>>>
>>>>>>> provide a really helpfull overview and later checking the code
>>>>>>>
>>> will be
>>>
>>>>>> much
>>>>>>
>>>>>>> simpler.
>>>>>>>
>>>>>>>
>>>>>>> Thanks in advance,
>>>>>>> Samuel.
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Serusers mailing list
>>>>>>> Serusers at lists.iptel.org
>>>>>>> http://lists.iptel.org/mailman/listinfo/serusers
>>>>>>>
>>>>>>
>>>> _______________________________________________
>>>> Serusers mailing list
>>>> Serusers at lists.iptel.org
>>>> http://lists.iptel.org/mailman/listinfo/serusers
>>>>
>>>
>
>
>> _______________________________________________
>> Serusers mailing list
>> Serusers at lists.iptel.org
>> http://lists.iptel.org/mailman/listinfo/serusers
>>
>
> _______________________________________________
> Serusers mailing list
> Serusers at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20070815/6e1772d5/attachment.htm>
More information about the sr-users
mailing list