I think the key here that end point suppose to indicate that it supports
changing To and From headers in the middle of the dialog. If such capability
is not indicated, changing headers is not allowed.
Roman Shpount www.telurix.com
___
Good Subject,
Looking into RFC-2543 the appropriate section to refer our issue would
be the below ones 11.2 and 11.4
11.2 Callee Issues Response
.
The UAS stores the values of the To and From field, including any
tags. These become the local and remote addresses of the call leg,
El Viernes, 19 de Febrero de 2010, Roman Shpount escribió:
> The same section says that complete To and From fields including any tags
> are stored as remote and local address. Subsequent requests in dialog
> should set their To and From headers to remote and local addresses, which
> are complete
The same section says that complete To and From fields including any tags
are stored as remote and local address. Subsequent requests in dialog should
set their To and From headers to remote and local addresses, which are
complete To and From headers. This is done to be compatible with RFC 2543,
wh
Roman Shpount wrote:
> From/To header should be preserved completely with all of its parameters
> to be compatible with RFC 2543. RFC 3261 Section 11.2 Callee Issues
> Response says that "The response MUST copy the To, From, Call-ID, CSeq
> and Via fields from the request." This implies that c
From/To header should be preserved completely with all of its parameters to
be compatible with RFC 2543. RFC 3261 Section 11.2 Callee Issues Response
says that "The response MUST copy the To, From, Call-ID, CSeq and Via fields
from the request." This implies that complete header, including all the
Hi, RFC 4826 allows the usage of and :
The element is similar to the element. Like
, it is only meaningful in documents obtained from an XCAP
server. It too is a reference to content stored elsewhere. However,
it refers to an entire list, and furthermore, it allows that list to
