Christer Holmberg writes:
> 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, 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.
these two issues currently make outbound useless to me (and i have not
read even half of the current version, so there may be many more in the
closet).
-- juha
_______________________________________________
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
