Hope that you have verified that BYE is received on the correct call-leg of
B2B UA. Suspect that such issue can happen if BYE is given on the other
UAS(INVITE) side of B2BUA.
-Harbhanu
On Mon, Jun 4, 2012 at 12:36 PM, Tarun2 Gupta wrote:
> Hi All
>
> Consider the following scenario:
&
log.
https://lists.cs.columbia.edu/pipermail/sip-implementors/2008-August/020143.html
But now what's confusing is this --
"The scope of these things is very unclear. About all you can
***reliably **assume
is that they are true at the time they are conveyed***. "
Regards,
Harbhanu
he below text for re-computation mentions that CSeq should not be
recomputed on receiving 2xx, since it might have changed owing to
mid-dialog requests.
Hope it helps.
Thanks,
Harbhanu
On Wed, Mar 21, 2012 at 2:58 PM, Vinay V wrote:
> Hi All,
>
>I wanted clarification re
transaction.
Thanks,
Harbhanu
On Tue, Mar 20, 2012 at 11:29 PM, Worley, Dale R (Dale)
wrote:
> > From: M. Ranganathan [mra...@gmail.com]
> >
> > Consider the following two scenarios:
> >
> > Scenario 1
> > =
> > Invite Client Transaction sent b
e network.
Thank you all !!
Thanks,
Harbhanu
On Fri, Mar 9, 2012 at 10:57 AM, Nataraju A.B wrote:
> Harbansu,
>
> 'Min-SE' header defined in view of avoiding *too frequent refreshes*,
> which might overload the adjacent proxies.
>
> Can you please share the scenario wh
fining 422 response code.
This can result is successful session establishment in cases where UAC
can accommodate this change.
Regards,
Harbhanu
On Wed, Mar 7, 2012 at 8:03 PM, Brett Tate wrote:
> > AFAIK RFC-4028 defines that proxy can reject with 422
> > to define a *higher minimum*
nks!
Regards,
harbhanu
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
e dropped each
such call, that would be a major headache for our tech support. We chose
to proceed with call setup.
On 2011-06-29 14:19, Harbhanu wrote:
> Considering that below we have a UAC named - "server"
>
> IMO both the below case should be rejected with failure response
e call here with 4xx response, when user answers?
Better would be to return a 5xx class response.
Regards,
Harbhanu
***
This e-mail and attachments contain confidential information from HUAWEI,
which is inten
ignore any session descriptions in subsequent responses to
the initial INVITE.
Please correct if I am missing anything here. Thanks!
Regards,
Harbhanu
***
This e-mail and attachments contain confidential information
As per my opinion these two should be explicitly carry the extension,
because of the proxy case.
Please share your opinion. Thanks!
Regards,
Harbhanu
***
This e-mail and attachments contain confidential infor
happens for dialog creating or target-refresh
request, then how valid is the case of modifying the port parameters of
"Contact" header ?
Thanks!
Regards
Harbhanu
***
This e-mail and attachmen
>The proxy should remove (after the necessary processing) all topmost
>routes that are recognized as its own (on the 16.4 step of rfc3261),
>otherwise on the next step (16.5 of rfc3261) it would have to forward
>the request to itself.
It should ONLY remove the first i.e. TOP MOST. In certain ca
implementations - i.e. using request spiraling
or removing both the routes in one go.
Regards,
Harbhanu
***
This e-mail and attachments contain confidential information from HUAWEI,
which is intended only for the person or
string is case-insensitive,
but implementations MUST send upper-case"
Does 3261 doesn't mandate any UAC to send version string in upper-case ?
And thus any UAC which doesn't do so isn't non-compliant to 3261 ?
To be precise - Is that ETSI testcase for 3261 conformance correct ?
phone or email immediately and delete it!
From: Iñaki Baz Castillo [i...@aliax.net]
Sent: 05 May 2011 16:09:56
To: Harbhanu sahai
Cc: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] Reg. SIP version string
2011/5/5 Harbhanu sahai :
> Is this testcase correct
61 doesn't explicitly mentions how UAS implementions need to handle such
requests.
Thanks!
Regards,
Harbhanu
***
This e-mail and attachments contain confidential information from HUAWEI, which
is in
(T1 is
defined in Section 17.1.1.1), the client SHOULD then consider the
original transaction cancelled and SHOULD destroy the client transaction
handling the original request.
Regards,
Harbhanu
***
This e
>> How about adding a new header something like "Remort-CSeq: 1" in 500
>> response?
There are two possible issues with this -
1. Attacker can sniff the response and change it to the valid value of Cseq
at UAC, thus leading to call drop.
2. Attacker can now join-in within any arbitrary CSeq,
>>CANCEL to the originator? Of course not. The proxy would send a 408 or
>>480 to the calling UA (to the UAC) and CANCEL to all the ringing
>>UAS's.
Here, 'ringing' is a very subtle but important point in your statement.
But how should the same be terminated incase any provisional is also not
rece
. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!
-Original Message-
From: Iñaki Baz Castillo [mailto:i...@aliax.net]
Sent: Friday, July 02, 2010 3:54 PM
To: Harbhanu
Cc: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-
se notify the sender by
phone or email immediately and delete it!
-Original Message-
From: Iñaki Baz Castillo [mailto:i...@aliax.net]
Sent: Thursday, July 01, 2010 2:35 PM
To: Harbhanu
Cc: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] Retrans 2xx handilng - RFC-4028
e this e-mail in error, please notify the sender by
phone or email immediately and delete it!
-Original Message-
From: Iñaki Baz Castillo [mailto:i...@aliax.net]
Sent: Thursday, July 01, 2010 12:27 AM
To: Vikram Chhibber
Cc: Harbhanu; sip-implementors@lists.cs.columbia.edu
Subject: Re:
timer, since retrans 2xx
also indicates that the peer is 'still alive'.
Thanks for your reply!
Regards,
Harbhanu
***
This e-mail and attachments contain confidential information from HUAWEI,
which is intend
DATE at transaction layer itself. Otherwise too, here UPDATE
could change many other parameters such as SE value & refresher, which
needn't be reverted after receiving 2xx of INVITE.
Please share your opini
prompt & close to absolute reply. :)
Regards,
Harbhanu
***
This e-mail and attachments contain confidential information from HUAWEI,
which is intended only for the person or entity whose address is listed
above. Any
aware of any of the existing commercial stack which supports the
same?
Thanks!
Regards,
Harbhanu
***
This e-mail and attachments contain confidential information from HUAWEI,
which is intended only for
> And basically an ACK a UAS receives is sent by a proxy.
> A proxy will have no credential.
But then the proxy is sending the ACK after being received an ACK, so can't
it *get* those credentials.
Also, on similar lines I too have one query, ACK retransmissions are to be
strictly handled done by U
Precisely, just to elaborate the transaction timeout for UPDATE vis-à-vis
re-INVITE is an interesting point to consider for selective usage.
***
This e-mail and attachments contain confidential information from HU
To update dialog parameter viz. contact or to update session parameters such
as 'sessiontimer' etc.
***
This e-mail and attachments contain confidential information from HUAWEI,
which is intended only for the per
Let say transaction DO take this responsibility
When will transaction stop the retransmission of this response??
***
This e-mail and attachments contain confidential information from HUAWEI,
which is intended
) by persons other than the intended recipient's) is
prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!
-Original Message-
From: Brett Tate [mailto:br...@broadsoft.com]
Sent: Monday, May 17, 2010 5:29 PM
To
our is correct or not.
Thanks in advance.
Regards,
Harbhanu
**
This e-mail and attachments contain confidential information
l
Uri ??
How are we supposed to handle scenarios like this ?
Regards,
Harbhanu
-Original Message-
From: Iñaki Baz Castillo [mailto:i...@aliax.net]
Sent: Saturday, February 28, 2009 6:19 PM
To: harbh...@huawei.com
Cc: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors
pvalue = 1*paramchar
paramchar= param-unreserved / unreserved / pct-encoded
unreserved = alphanum / mark
mark = "-" / "_" / "." / "!" / "~" / "*" /
"'
;Refer-To" also follows same normative rule, as it's
also obtained from name-addr / addr-spec ??
I couldn't find any normative statement in rfc-3515 for this. Thanks!
Regards,
Harbhanu
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
36 matches
Mail list logo
