-Original Message-
From: Dale Worley [mailto:dwor...@nortel.com]
Sent: Tuesday, August 18, 2009 1:37 AM
To: T Satyanarayana-A12694
Cc: Paul Kyzivat; sip-implementors@lists.cs.columbia.edu
Subject: RE: [Sip-implementors] Can EP send media only peer supports
On Sat, 2009-08-15 at 23:35 +
Dale Worley wrote:
> On Sat, 2009-08-15 at 23:35 +0800, T Satyanarayana-A12694 wrote:
>> Additional round trips should be made optional (only for implementations
>> having concurrent codecs limitation).
>>
>> Additionally, why can't the spec be modified (or place in a BCP):
>> 1. to allow only a
Bhaskar Dutta wrote:
>> I had a doubt on History-info header present in Sip 18x Responses.
>>
>> Are the History-info headers UAC received in 18x response useful to an
>> application or user ?
>>
>> If yes can you please quote an example where its useful to an
>> application/user .
This is entir
On Sat, 2009-08-15 at 23:35 +0800, T Satyanarayana-A12694 wrote:
> Additional round trips should be made optional (only for implementations
> having concurrent codecs limitation).
>
> Additionally, why can't the spec be modified (or place in a BCP):
> 1. to allow only a sub-set (of what is presen
> I had a doubt on History-info header present in Sip 18x Responses.
>
> Are the History-info headers UAC received in 18x response useful to an
> application or user ?
>
> If yes can you please quote an example where its useful to an
> application/user .
>
> How should the UAC's treat these HI
Paul,
I haven't seen SIPit collecting stats at this level (it is usually at
feature level). But, it will be a good exercise to collect this at next
SIPit or even solicit implementor opinion on this mailing list.
Regards
Satya T
-Original Message-
From: sip-implementors-boun...@lists.cs.c
AFAIK, this is not valid.
>From RFC3555, annexb: indicates that Annex B, voice activity detection,
is used or preferred
>From RFC3108, silenceSupp: indicates the use or non-use of silence
suppression
(The second one is less used and may not be understood by many
implementations).
In your example
We can not see the attachment. A UAC should have no problem processing
a unreliable 18x response without Contact as it is optional.
It is definitely needed in a reliable 18x as without it, a UAC can not
construct a PRACK request. In this case, 18x will timeout and the
early dialog will be terminate
Hi All,
While negotiating G729 codec is it valid to have "annexb=yes" and
"silenceSupp:off" in the initial offer being offered assuming that far end
supports all of these capabilities?
For example:
m=audio 8804 RTP/AVP 18 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=ye
Rockson Li (zhengyli) wrote:
> Paul,
>
> If I catch you clearly, do you mean this is a real bug in RFC3264?
IMO this is unclear. It might be that what is written is not exactly
what the original authors intended. Or maybe it is as intended but isn't
what people now wish had been written.
Eit
The attachment didn't survive the lists filtering.
The answer can likely be found on the following thread:
https://lists.cs.columbia.edu/pipermail/sip-implementors/2008-August/020062.html
> -Original Message-
> From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-
> implemen
What should be the behaviour, in case 18X response is received with no
Contact header for the below case?
Please refer the attached document for sample scenario.
The entity is behaving as a B2B, where BYE is received from one side.
Thanks,
kumar
___
Si
What should be the behaviour, in case 18X response is received with no
Contact header for the below case?
Please refer the attached document for sample scenario.
The entity is behaving as a B2B, where BYE is received from one side.
Thanks,
kumar
___
Si
Session Timers detect availability of session and is restricted to an existing
dialog.
On the other hand, OPTIONS can be used outside of a dialog(session/call)
independently, to determine the larger availability of SIP UA at the far end,
even if on a per hop basis.
Both Session Timers and OPTI
Hi All,
I had a doubt on History-info header present in Sip 18x Responses.
UACUAS
| |
|- INVITE -- -->|
| Supported:
Hello
I have a question about translating ISUP redirecting reason values to
SIP Diversion reason values.
In draft-levy-sip-diversion-10 section 10.1 there is a limited list of
translations between ISUP and SIP diversion reason codes:
ISUP/ISDN reason code Diversion reason code
00
Hi Indresh:
Thanks for explanation.
On your following point, lets consider another scenario for SIP->PSTN
> But let us say for some reason if the orginating guy is interested in
> uniquely knowing the ISUP side cause value and reason rather than
> referring to > this ISUP-SIP
17 matches
Mail list logo
