Let’sassume a session is in place, established through an offer/answer exchange
witha single media stream (i.e. a single m line).
Then, theUAC A sends a reINVITE containing an SDP offer having two m lines, and
theoffer is rejected by the UAS B (let say with a 488).
Thequestion is about the numb
Hi all,
RFC3960, gateway model, says basically: once you receive a 180 ringing plays
a local ringback UNLESS you are actually already receiving a stream. This
should mean that in case an RTP stream is flowing, you have to "ignore" the
180 and continue playing the stream. Note that in field scenari
I basically agree (as almost usually) with Paul. From the protocol
compliancy point of view, adding a new m line for the T.38 stream
(regardless it is the first or the second one, both options are allowed in
my interpretation of RFC3264) is allowed as well as replacing the first one,
formerly audio
I basically agree (as almost usually) with Paul. From the protocol
compliancy point of view, adding a new m line for the T.38 stream
(regardless it is the first or the second one, both options are allowed in
my interpretation of RFC3264) is allowed as well as replacing the first one,
formerly audio
There's no a standard way to renegotiate the T.38 media. Usually it is the
called party that issues the reINVITE, but there are implementations where
the reINVITE is sent by the calling party once the CNG is detected (of
course in the most common scenario where the calling party is the one
sending
Answering with inactive may also be used to save bandwidth (in addition to
DSP resources as already mentioned) in the call hold scenario. Inactive will
force the holding party to stop sending media, leaving the held party to
generate proper notification to the user (a message, a special hold tone o
According to your call flow, it appears Broadsoft server acts in a
proprietary way that doesn't fit the usual switchover to T.38. Here my
opinions:
Problem 1
The parameters you mention (and maybe you expect) are all optional but
T38FaxRateManagement, which is the only mandatory parameter. Btw, fro
Sorry, I reported the wrong RFC number, the right one is 3398 "SIP-ISUP
mapping". I beg your pardon
Andrea
-Original Message-
From: Paul Kyzivat [mailto:pkyzi...@cisco.com]
Sent: mercoledì 21 gennaio 2009 17.29
To: Andrea Rizzi
Cc: sip-implementors@lists.cs.columbia.edu
S
I'm coming back to an old question as it appears to me RFCs says differently
about.
Quoting an old answers from Paul:
"If user=phone is present, then the syntax of the user part must conform
with the TEL URI syntax as defined in RFC 3966.
That syntax says that the number must start wi
Brett,
Could you please clarify why an unreliable provisional response doesn't
complete an offer/answer? IMO, when a UAC send an offer on the Invite, the
SDP included in the first provisional response closes the offer/answer
exchange, regardless it is reliable or not. The UAS, of course, cannot be
IMO, dynamic payload "negotiation" follows the same rules for the audio
codecs. From my point of view, there's no a real negotiation (let say
H.323-like) in RFC3264 (i.e. the RFC you would refer to), unless you change
some SHOULD or RECOMMENDED in Section 6.1 to MUST. Then, despite suggested,
it is
The title says the opposite of the mail's contents, btw:
RFC3960, gateway model gives guidelines about the, let's say, "correct"
behavior. The main rule says more or less "media has always the precedence".
About the scenario you mentioned in the text, i.e. 183/SDP and then 180 (no
SDP I assume) you
Regarding
" The best recommendation I have seen (don't remember where it was
written) is that you should render a local ringback if you get a 180
*and* are not receiving media"
The behavior is suggested by RFC 3960, gateway model.
I basically agree with Paul. Any RFC will say what the client h
EFER method.
Andrea
-Original Message-
From: Vikram Chhibber [mailto:[EMAIL PROTECTED]
Sent: mercoledì 28 novembre 2007 19.42
To: Andrea Rizzi
Cc: sip-implementors@lists.cs.columbia.edu; [EMAIL PROTECTED]
Subject: Re: [Sip-implementors] Sip-implementors Digest, Vol 56, Issue 28
Andrea, I w
Sanjay,
Below you said:
-
If user2 disconnects before transfer is complete, user1 can choose not
to send final Notify once the outcome of transfer is known. Or even if
it does, since user2 does not have sense of the call leg with user1, it
will send 481 response to that Notify.
-
In case
IMO, when User 2 disconnects after transferring the call, from the user
perspective it leaves the former calls, while it is not involved at all in
the transferred call. From the signaling perspective, when disconnecting
(after REFERring the first call) it sends a BYE closing the first call. The
tra
Attila,
The '*' char shall not be escaped IMO, this is allowed by RFC 2396 in URI
syntax. Have you references saying the '*' should be escaped?
Andrea
--
Message: 3
Date: Wed, 14 Nov 2007 15:11:41 -0600
From: Robert Sparks <[EMAIL PROTECTED]>
Subject: Re: [Sip-imple
Paul,
Just a note about your answer
.
SIP has no mechanism that tells the other party that the HOLD feature
has been invoked. The sendonly/recvonly/inactive mechanism can be *used*
when HOLD has been invoked locally, to optimize the use of the media
path. But the same mechanisms are a
Just read section 6.1 .
Should the attribute be missing in the answer, it implicitly means sendrecv,
i.e. it is forbidden!
Andrea
-Original Message-
From: David Benoit [mailto:[EMAIL PROTECTED]
Sent: mercoledì 27 giugno 2007 16.21
To: Andrea Rizzi
Cc: 'varun'; sip-im
Option 3 is forbidden by RFC3264!
Andrea
-Original Message-
From: David Benoit [mailto:[EMAIL PROTECTED]
Sent: mercoledì 27 giugno 2007 15.20
To: varun
Cc: Andrea Rizzi; sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] Call hold and a = inactive
Hi,
The exchange
There are no violations at all in responding with inactive, and as you
mentioned this will suspend any media, as the holding procedure is
definitively a new offer/answer exchange.
Actually, in my opinion, this would be the preferred way to implement the
call hold service, to save bandwidth, of cou
21 matches
Mail list logo
