Hi, I have a doubt regarding GRUU (draft-ietf-sip-gruu-06) and outbound draft (draft-ietf-sip-outbound-01)
1> The outbound draft states that if the UA has to support outbound draft then it has to include the sip.instance-id and flow-id in the contact header. In this case its possible that a single device associated with the AOR can have multiple contacts (connections) to the Registrar/Proxy. As, a result the outbound supports flow-id(i.e. connection identifiers) to a single device ( sip.instance-id). The GRUU draft states that if the UA has to support GRUU then it has to include the sip.instance-id in the contact header along with the supported header field value as "gruu". The GRUU is a combination of instance-id and AOR pair (i.e instance-id / AOR). If the UA supporting GRUU registers with multiple contacts in single REGISTER message, then each contact has to have a different instance-id for an AOR to support GRUU (i.e we can have only one GRUU per AOR/instance-id.). As instance-id varies, the contact device also varies. This means only one contact/connection to a particular device for an AOR. Hence, can we assume that maintaining a mapping for GRUU and the connection-id is sufficient to identify the flow to a contact behind a NAT (assume that we want to maintain the flow information between the UA and Registrar/Proxy for connection reuse to support the NAT traversal). Hence, from the GRUU draft explanation it seems that there can be only one connection to a device. (instance-id/AOR pair). Hence, from both the above drafts can one conclude that if GRUU is being supported for NAT traversal then flow-id concept of outbound draft will not be required (the GRUU will server the purpose of flow-id). 2> Can there be a scenario where a UA (supporting GRUU) registers with two contacts in a single REGISTER message. The condition being that one contact has the instance-id and the other contact does not have the instance-id and also that the supported header field should have the value as "gruu". If this scenario is possible then how should the second contact not having the instance-id be handled when the supported header field has value "gruu" ? 3> If we want to support NAT traversal using connection reuse and GRUU then should there be only one contact per registration for UA's supporting GRUU ? 4> Is NAT traversal possible using third party registration in case of GRUU (assuming the contact being registered is behind a NAT). There would be no connection between the contact being registered and the Registrar/Proxy. Hence, no one can reach the contact in the private domain). Is it to be mandated that third party registrations are not allowed if NAT traversal is required using GRUU? Regards, _______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
