Thanks a lot, now I understand.
regards
klaus
Paul Kyzivat wrote:
> inline
>
> Klaus Darilion wrote:
>> Hi all!
>>
>> RFC 3261 explicitly allows the having multiple contacts in a single
>> header.
>>
>> > 7.3: ... Specifically, any SIP header whose grammar is of the form
>> >
>> > header
On Tue, 2009-04-07 at 00:39 -0700, sudhagar wrote:
> I feel that once the UAS has received BYE and honored it, it should
> naturally stop the retransmission of all pending responses as
> transaction is terminated).
You are incorrect. Each request starts a separate transaction, and each
transacti
inline
Klaus Darilion wrote:
> Hi all!
>
> RFC 3261 explicitly allows the having multiple contacts in a single header.
>
> > 7.3: ... Specifically, any SIP header whose grammar is of the form
> >
> > header = "header-name" HCOLON header-value *(COMMA header-value)
> >
> > allows for com
Hi all!
RFC 3261 explicitly allows the having multiple contacts in a single header.
> 7.3: ... Specifically, any SIP header whose grammar is of the form
>
> header = "header-name" HCOLON header-value *(COMMA header-value)
>
> allows for combining header fields of the same name into a com
El Miércoles 08 Abril 2009, Paul Kyzivat escribió:
> "forget negotiation". Look at the base note of this thread. The guy
> needs a way to negotiate between INFO and 2833.
>
> Our products support 3 or 4 ways of sending DTMF. And ad hoc means of
> negotiating among them have been developed.
>
> Norm
Iñaki Baz Castillo wrote:
> El Martes 07 Abril 2009, Scott Lawrence escribió:
>
>>> How is possible a RFC (2976) not being a a standard and a draft being it?
>> That RFC only defines the INFO method, but not how DTMF or anything else
>> is transported using that method:
>>
>>The definition o
Hi,
Does anyone know an open source MSML parser ?
Thanks in advance.
Claire.
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
El Martes 07 Abril 2009, Scott Lawrence escribió:
> > How is possible a RFC (2976) not being a a standard and a draft being it?
>
> That RFC only defines the INFO method, but not how DTMF or anything else
> is transported using that method:
>
>The definition of the message bodies or any new he
On Tue, 2009-04-07 at 22:02 +0200, Iñaki Baz Castillo wrote:
> El Martes 07 Abril 2009, Paul Kyzivat escribió:
> > The info method is unofficial and non-standard.
> > One of its limitations is that it *isn't* negotiated.
> >
> > The "official" ways are:
> > - kpml event package
> >(draft-ietf-s
On Wed, 2009-04-08 at 01:23 +0530, Nagendra Swamy Honnalagere Shivanna
wrote:
> Hi all,
>
> Is there a standard mechanism defined to generate 'nonce' value used
> in Digest authentication for SIP?
The server is free to use any method it wants to. That method should
ensure that it is hard to gues
El Martes 07 Abril 2009, Paul Kyzivat escribió:
> The info method is unofficial and non-standard.
> One of its limitations is that it *isn't* negotiated.
>
> The "official" ways are:
> - kpml event package
>(draft-ietf-sipping-kpml-08
How is possible a RFC (2976) not being a a standard and a d
The info method is unofficial and non-standard.
One of its limitations is that it *isn't* negotiated.
The "official" ways are:
- in the rtp media itself
- rfc2833 in the media stream
- kpml event package
(draft-ietf-sipping-kpml-08, which is done except for
dependency, on gruu I think.)
In
Hi all,
Is there a standard mechanism defined to generate 'nonce' value used in Digest
authentication for SIP?.
Also, is it MANDATORY for UA to re-submit request having credentials with same
call-id for which it received challenge?
I mean, is the following is valid?
UA1 (INVITE Cal
Sending dtmf tones over sip can be done in 2 ways, SIP INFO or RFC2833. Using
RFC2833 is negotiated in the SDP message as Media Attribute (a): rtpmap:101
telephone-event/8000. In SDP is negotiated if this media attribute is used or
not, but when sending dtmf as SIP INFO there is no negotiation,
Can some one suggest, what is the best way to test for ISC compliance
in IMS application server?
regards
sankar
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Hi All,
Sorry to have posted ASR related query! Dint find the relevant thread for
the same.
If anyone is aware of (CMU's Automatic Speech Recognizer) Sphinx usage,
please do let me know about the same as it involves (building) many modules
for making a system work.
Also if anyone has an idea about
You should always see 200 OK retransmissions in this case, until the UAS
receives the ACK or the transaction times out.
On receiving BYE, the transaction layer would treat it as a different
transaction altogether and wont try to relate it in anyway to the INVITE
transaction. Thus transaction layer
Hi,
I would like to know, what should be the behavior of UAS, when
receiving a BYE for an INVITE transaction, to which 200 OK has already been
sent, but instead of UAC sending an ACK sends a BYE after receiving 200 OK for
INVITE. I currently see that our UAS responds with a 200 OK to t
18 matches
Mail list logo
