Re: [Technical Errata Reported] RFC4028 (1681)

"Dale Worley" <[email protected]>
Newsgroups gmane.ietf.sip
Organization Nortel Networks
Message-ID <[email protected]>
On Tue, 2009-02-10 at 11:56 -0500, Bob Penfield wrote:
> The text in 8.1.3.5 means that the From and To headers in the new
> INVITE should have the same value including tags as the rejected
> INVITE. If it was an initial (out-of-dialog) INVITE, there will be no
> to-tag in the To, and thus the re-submitted request will not have a
> to-tag either. There is no need to change the Call-ID or the from tag
> because no dialogs were created.
>  
> If it is an in-dialog request, it must have the same tags otherwise it
> will not match the dialog. This could happen if authentication is
> required for in-dialog requests and the UAC did not include the
> credentials, or the credentials are stale.
>  
> From an implementation point of view, it is simpler if the procedures
> for re-submitting requests for repairable 4xx errors are the same for
> in-dialog and out-of-dialog requests.
>  
> I see no reason to change the Call-ID or from tag.

All of the above matches my understanding and the discussions that I've
seen here.
 
> As for the question "If the From tag doesn't change, can the UAS
> retrain the same To tag as well?", I would say that UAS should not use
> the same to-tag for a new request.

I'm sure that the UAS should not use the same to-tag in its response to
the new request -- the first request did not establish a dialog, so the
second request could not be part of that dialog.  And indeed, it would
be difficult to build a UAS that did use the same to-tag, as it would
have to remember the to-tag it used in the first request and use it in
the second -- but nonetheless, if it received two copies of the first
INVITE and rejected both, it would have to use different to-tags for the
two error responses.

Dale


_______________________________________________
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.