Re: Dual registration without Outbound

Hi,

>>The only new thing is that the USER may use different contacts for
>>different flows. BUT, it is still the same USER, and that USER should
>>still register at least two register flows - either all flows from the
>>same contact, or from different contacts.
>> 
>>As far as I know, you have never before requested that the registrar,
>>for incoming requests, shall perform paralell forking on all registered
>>flows.
>
>it is not SHALL, but it MUST BE POSSIBLE to do if the user wants that to
>happen.
>
>in my example the same UA instance registers AoR sip:[email protected] over
>its gprs and 3g interfaces with different contact addresses (one from
>ggsn and the other one from lan).
>
>first, like today without outbound, it must be possible with outbound
>that incoming call to sip:[email protected] gets parallel forked to the two
>contacts of this UA instance.  now i tried to figure out what ob draft
>says about it and found this:
>
>7. Authoritative Proxy Procedures: Forwarding Requests
>
>   When a proxy uses the location service to look up a registration
>   binding and then proxies a request to a particular contact, it
>   selects a contact to use normally, with a few additional rules:
>
>   o  The proxy MUST NOT populate the target set with more than one
>      contact with the same AOR and instance-id at a time.
>
>to me this clearly means that parallel forking is not anymore possible
>when UA implements outbound,

Ok, I admit I forgot about that text.

>which would be a VERY SEVERE restriction and change of RFC3261 behavior.
>
>second, if the UA instance may choose to register one of its two
>contacts via ob proxy 1 and the other via ob proxy 2, it makes
>simple implementation of redundancy with two proxy/registrar pairs
>impossible.

So, does the outbound spec forbid registering each contact via two proxies? Or, do you want to mandate THAT?

Regards,

Christer


_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip