Thanks Brett-
If a device truly does not want to receive or reply to requests after the
ephemeral port tcp connection has been reclaimed, it can do as you are
describing. Otherwise, using your presented solution would require the
device to provide the updated Contact on all relevant dialogs after the
connection gets re-established.
Interesting. I fall into the first category for now, although I'm
interested in long term interoperability. I'm working on a p2p SIP
implementation that's far outside your typical scenario, so I may just
get it working using this solution for now, moving to outbound and reuse
draft compliance down the road.
GRUU was only mentioned within the Introduction and Problem Statement
sections. GRUU is not required for connection reuse per the reuse draft.
Additionally, Rohan has received comments that section 2.2 should
potentially be removed since the section applies more to the outbound draft.
Interesting -- I'll give it a more thorough read. Thanks very much for
your thorough answers.
Best,
Adam
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
