On Tue, Nov 25, 2008 at 1:44 AM, Rockson Li (zhengyli)
[EMAIL PROTECTED]wrote:
I wonder why you think the first subscribe fails with a 500 due to out
of order CSeq number.
Sine the second one would be sent with Cseq+1 as in first one.
I don't see out of order CSeq number issue here.
Paul
Rockson Li (zhengyli) wrote:
Paul,
I wonder why you think the first subscribe fails with a 500 due to out
of order CSeq number.
Sine the second one would be sent with Cseq+1 as in first one.
I don't see out of order CSeq number issue here.
Well, the scenario says that the 2nd subscribe
El Martes, 25 de Noviembre de 2008, vamshi dommeti escribió:
Hi All ,
Can any one explain which SIP header could be a better option for
sending Caller-ID information .
We have a SIP-GSM gateway on which we would like to send the Caller-ID
information consisting of GSM Mobile
On Tue, Nov 25, 2008 at 3:39 PM, Iñaki Baz Castillo [EMAIL PROTECTED] wrote:
Hi, whatever cool RFC's/draft's say, the fact is that most of SIP end points
(AKA phones) use From header to render the CallerID to the *human* and
they ignore P-Asserted-Identity or deprecated Remote-Party-Id headers.
El Martes, 25 de Noviembre de 2008, Victor Pascual Ávila escribió:
On Tue, Nov 25, 2008 at 3:39 PM, Iñaki Baz Castillo [EMAIL PROTECTED] wrote:
Hi, whatever cool RFC's/draft's say, the fact is that most of SIP end
points (AKA phones) use From header to render the CallerID to the
*human* and
25 nov 2008 kl. 18.11 skrev Iñaki Baz Castillo:
El Martes, 25 de Noviembre de 2008, Victor Pascual Ávila escribió:
On Tue, Nov 25, 2008 at 3:39 PM, Iñaki Baz Castillo [EMAIL PROTECTED]
wrote:
Hi, whatever cool RFC's/draft's say, the fact is that most of
SIP end
points (AKA phones) use
El Martes, 25 de Noviembre de 2008, Johansson Olle E escribió:
As you say, it's important to show both the calling URI - which is
corresponding
to the Caller ID number in ISDN - and the Caller ID name. Just showing
the
Caller ID name - or display name - is not a good solution at all.
How to
El Miércoles, 26 de Noviembre de 2008, Fernando Mercês escribió:
Hello.
I need to understand the source of my problem with SIP trunk and my
voicemail server. I have a
PBX that receive an SIP response 415 -
Unsupported Media Type from voicemail server.
Here the conversation packets when I
Thank you by the interest, Iñaki.
I don't know the answer to this new INVITE from PBX. In a normal
operation, the RTP traffic should be initiated, right?
About the RFC, so, the server (voicemail in this case) do not send the
list of acceptable codecs, unfortunately. Tha language (en-us), type
El Miércoles, 26 de Noviembre de 2008, Fernando Mercês escribió:
Thank you by the interest, Iñaki.
I don't know the answer to this new INVITE from PBX. In a normal
operation, the RTP traffic should be initiated, right?
About the RFC, so, the server (voicemail in this case) do not send the
Hi
Which one will be better approach for checking the SIP session is
still active or not? Session Timer or OPTIONS ping. And Why?
Regards
S.Radha krishna
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
Hi
Ping will only guarantee about the presence of the end user but not about
the session if it is present or not, and in case of session time it will
only claim, session is present if end user is present, so in order to have
good solution to your problem you need to check both i.e. session time
Hi Radha,
A Session Timer refresh is a better option to check whether a SIP
session is alive or not.
Because OPTIONS can be sent outside a dialogue too.A session timer
re-INVITE/UPDATE will
always be sent within a dialog, so its response is the most reliable way
to determine whether
a session is
25 nov 2008 kl. 18.46 skrev Iñaki Baz Castillo:
El Martes, 25 de Noviembre de 2008, Johansson Olle E escribió:
As you say, it's important to show both the calling URI - which is
corresponding
to the Caller ID number in ISDN - and the Caller ID name. Just
showing
the
Caller ID name - or
14 matches
Mail list logo
