Jeroen,
Abstractly I understand your issue, and it seems valid, though I would
like to think about it a bit.
But I'm trying to think of why you would want to do this. If a single UA
registers multiple contacts with the same AOR, then it is pretty likely
that incoming calls will be delivered to the UA multiple times. That
seems like an undesirable situation.
Paul
Jeroen van Bemmel wrote:
All,
While trying to implement GRUU and outbound in combination, I stumbled
upon a minor issue: what if the UAC uses different Contact URIs when
registering multiple flows. The examples in outbound don't do this, but
there is no explicit statement that this is not allowed, and the example
in 3.2 ([EMAIL PROTECTED]>;reg-id=1
<mailto:[EMAIL PROTECTED]>;reg-id=1>) could be seen as suggesting that
the registration with reg-id=2 would use "line2"
See my previous mail: for GRUU this could mean that the authorative
proxy cannot select the right URI to rewrite with, there can be an
inconsistency between the temporary GRUU the UAC selected (associated
with a specific contact) and the request URI received.
One solution may be to adapt the algorithm used to generate temporary
GRUUs. A second option, which is perhaps simpler, is to simply state in
outbound that the UAC MUST use identical Contact URIs when registering
multiple flows (in section 4.2), and that the authoritative proxy MAY
select any one of the registered Contact URIs to rewrite with (e.g.
needed to cover transitional cases where the UAC obtains a new IP
address and starts re-registering)
Regards,
Jeroen
------------------------------------------------------------------------
_______________________________________________
Sip mailing list https://www1.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
_______________________________________________
Sip mailing list https://www1.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
