If you are mentioning about a proxy then proxies need not to remove it
exception is "anonymous" calls.
Is it a B2BUA you are mentioning? Not sure whats the action in that case.
On Fri, Mar 11, 2011 at 8:01 PM, Yves Dorfsman wrote:
>
> If a registrar forwards an INVITE to a UA, is it supposed to
On 03/11/2011 08:31 AM, Yves Dorfsman wrote:
> If a registrar forwards an INVITE to a UA, is it supposed to leave the
> "User-Agent:" in place, or does it replaces it with "Server:"?
>
>
> Thanks.
If an entity is forwarding INVITEs, it is not acting as a registrar. It
should continue using "User-A
please remove s...@ietf.org from any further responses to this thread.
On Mar 9, 2011, at 4:30 AM, Jaiswal, Sanjiv (NSN - IN/Bangalore) wrote:
> Hi Nitin,
>
>
> Every SDP with incremented session ( in this case 200 OK) is treated as
> new negotiation(offer).
> Whether ACK from other end contain
Please remove s...@ietf.org from any further responses to this thread.
On Mar 10, 2011, at 6:34 AM, Saúl Ibarra Corretgé wrote:
> I'd do 305 in this one, but that's just my 2 cents.
>
>
> On Thu, Mar 10, 2011 at 11:16 AM, isshed wrote:
>> Hi All,
>>
>> If an initial INVITE from an endpoint of
On 11-03-10 12:09 AM, Joegen E. Baclor wrote:
> On 03/10/2011 11:36 AM, Evgeniy Khramtsov wrote:
>> From the RFC (3261 and 2617) it is unclear for me whether the "uri"
>> parameter (aka digest-uri) in the WWW-Authorization or
>> Proxy-Authorization header is case-insensitive or not. For instan
If a registrar forwards an INVITE to a UA, is it supposed to leave the
"User-Agent:" in place, or does it replaces it with "Server:"?
Thanks.
--
Yves. http://www.SollerS.ca/
http://blog.zio
2011/3/10 Brett Tate :
>> I need to know is there any significance of a modified PAID
>> header in Re-INVITE.
>
> RFC 5876 provides some information on the topic.
3.2. Inclusion of P-Asserted-Identity in Any Request
In one example, an established call passes through a gateway to the
PSTN
>>Also, different SDP in 200 OK will be considered as new offer only when
>>offer-answer is done previously through reliable 18X response.
No, the SDP in the 200 OK should be ignored in this case.
Once an INVITE's offer/answer has been completed there
cannot be another offer/answer for that INVIT
Hi Sanjiv,
I don't think I understand your question.
But let me say what I mean in a different way:
After INV/18x/PRACK/200(of PRACK), there can be
no more offer/answers for the INVITE transaction.
So even if there is SDP in the 200 OK, it should not
be considered to be a new offer - it should ju
Hi Sanjiv,
You are talking about the positive scenario. And moreover what you are
saying is correct only when 183 is a reliable response (RFC wise).
Also, different SDP in 200 OK will be considered as new offer only when
offer-answer is done previously through reliable 18X response.
There could b
Hi Attila,
Take for example the early media is established with
invite/18x/PRACK/200k(of PRACK).
Now announcement is played and after that if endpoint want to change the
media( for established dialog) then as per you mention , end point has
to send update with change media stream. And Sending
Hi Sanjiv,
The behaviour you describe is not permitted.
As Bob Penfield correctly said:
There can be only one offer/answer in a single INVITE transaction. There can be
a second offer/answer exchange on an early dialog (i.e. before the 200 on the
INVITE), but that second offer/answer must be in
Hi Ashok,
The SDP from 183 is considered as Answer of initial offer.
Different SDP in 200 OK is considered as new offer and then it is must
to send the ACK with SDP answer for second negotiation to successful.
Regards
Sanjiv
-Original Message-
From: sip-implementors-boun...@lists.cs.co
>>RFC 3261 does not talk about this.
RFCs do not and cannot consider every error combination.
>>Only when the same answer is placed in 18X and 200
>>then only the SDP in 18X will be considered as an answer.
The RFC clearly says that the first received SDP will be the answer.
And the SDPs of 18
Hi Attila,
Agree with you but what happens when 183 and 200 OK have different SDPs from
the terminating endpoint. Then which SDP should be considered as an answer.
RFC 3261 does not talk about this. And in case of Nitin's scenario, SDPs are
different since session version is incremented (though al
15 matches
Mail list logo
