[Serdev] maddr parameter support for REGISTER

[Andrew Mee]

Quick question regarding this... I assume the subst_uri is supposed to 
work on the whole message?
Because it seems this command only looks at the RURI..... Which seems to 
mean this never works.

Sorry if I have this wrong.

Andrew

Jiri Kuthan wrote:

>I think 2 is more appropriate -- we should better conserve protocol
>elements as received and just interpret them differently.
>
> In simple cases, you don't even need to change code:
> subst_uri("/(sip:)([a-zA-Z0-9_.!~*'()%&=+$,;?-]+@)?([a-zA-Z0-9.-]+)(:[0-9]+)?(;.*)(maddr=)([0-9.]{7,15})/\1\2\7\4\5\6\7/");
>  (shortcvoming: subs_uri applies only to the first uri in destination set.
>   when forking, other branches will not be processed.)
>
>-jiri
>
>ps
>
>  besides that I think that such usage of maddr is fundamentally broken.
>  originally maddr was created for use with multicast. When the rather
>  imperfect strict-routing was introduced in RFC2543, maddr was overloaded
>  to handle with its defficiencies. We don't need to do that, there is
>  loose routing in 3261, overloading of protocol elements is a bad practice.
>
>
>
>At 07:09 PM 8/25/2004, Maxim Sobolev wrote:
>  
>
>>Folks,
>>
>>One of our clients bumped into the problem with Nortel's softphone. The phone uses maddr URI parameter to indicate its own IP address in the Contact header of the REGISTER request. That is, it puts SIP server's IP into host portion of URI and its own IP address into maddr parametr. Since SER has no special handling for maddr, after successful lookup() it sends request to itself, instead of sending it to the UA.
>>
>>According to RFC, if URI contains maddr parameter it should be used instead of host portion of the URI when forwarding message to that URI. Therefore, it seems that phone behaves correctly.
>>
>>In my opinion there are two ways to resolve this problem:
>>
>>1. Extend save() function to replace host portion of the URI with the maddr value if present and remove maddr parameter before saving contact into the location database.
>>
>>2. Extend forwarding logic to respect maddr parameter when deciding where to send the message.
>>
>>What do you think?
>>
>>-Maxim
>>
>>_______________________________________________
>>Serdev mailing list
>>serdev at lists.iptel.org
>>http://lists.iptel.org/mailman/listinfo/serdev
>>    
>>
>
>--
>Jiri Kuthan            http://iptel.org/~jiri/ 
>
>_______________________________________________
>Serdev mailing list
>serdev at lists.iptel.org
>http://lists.iptel.org/mailman/listinfo/serdev
>  
>


-- 
Andrew Mee