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
