Hi,
this seems to be a proprietary parameter of Sonus SBC':
https://support.sonus.net/display/SBXDOC61/Sip+Headers+And+Parameters+-+Flags
If enabled, the SBCincludes a set of specific PSTN parameters in a
> pstn-params= entry in outgoing INVITE messages. The PSTN parameters
> currently included
Hi,
this seems to be a proprietary parameter of Sonus SBC':
https://support.sonus.net/display/SBXDOC61/Sip+Headers+And+Parameters+-+Flags
If enabled, the SBC includes a set of specific PSTN parameters in a
> pstn-params= entry in outgoing INVITE messages. The PSTN parameters
> currently included
Hi Ranjit,
I can't answer the question, but I have another question:
Isn't the connection and relation to the UE maintained by the P-CSCF?
>From my perspective the S-CSCF does not have any relation to the UE.
BR
Philipp
___
Sip-implementors mailing lis
This was most likely a typo, RFC 3264 describes SDP offer/answer model.
Am Di., 24. Sept. 2019 um 07:40 Uhr schrieb Sundbaum Per-Johan (Telenor
Sverige AB) :
> Thank you, really helpful, but I need help on what I should look for in
> RFC3265, I can't find that there is any mention of SDP's in it
RFC 4028 describes Session Timers in SIP.
RFC 3264, 4317, 4566, 6337 describe SDP as well as SDP offer/answer model.
RFC 6141 describes Re-INVITE and Target-Refresh Request Handling in the
Session Initiation Protocol (SIP).
Hope this helps
___
Sip-imp
It is perfectly fine to Re-Invite to an audio conversation after
transmitting data.
But this is actually only relevant when you are talking to somebody, then
transmit data and talk again.
When this session is only established to transmit data you can end the
session after data transmission is fini
Are the different SIP183 in the same dialog or are this different dialogs?
Is the SIP183 sent reliable (Require: 100rel with PRACK-procedure)?
Does this c-line apply on the session or media level?
See RFC4566, 5.7. Connection Data ("c=") for more details...
___
Does this INVITE only contain one media-line (image) or additional m-lines?
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Sonicwall Firewalls are dropping fragmented SIP packets beginning with
SonicOS 5.8 by default. This is justified by the following sentence:
> Fragmented UDP traffic, especially SIP traffic, is a clear violation of
> RFC protocol, which SonicOS Enhanced firmware 5.8 and above very strictly
> adhere
> There are a lot of good reasons of not using STUN but there are no good
> reasons of not using STUN for UDP keep-alive. STUN keep-alive is extremely
> easy to implement. It is possible to verify packet validity and it can be
> used to detect local IP change.
Do you know any implementation (=p
>
>
> If UDP is used for transport, empty UDP packets can be sent to keep the
>> NAT-binding alive.
>>
>
> Sending empty UDP is not standard complaint. Sending a STUN binding
> request, as described in https://tools.ietf.org/html/rfc5626#section-3.5.2
> is safer.
>
This is not an option, if you ar
There is no need to send REGISTER-Requests this often.
This will generate unnecessary load on the application level.
If UDP is used for transport, empty UDP packets can be sent to keep the
NAT-binding alive.
When TCP is used, the method mentioned in RFC5626, 3.5.1 can be used to
keep the NAT-bindi
There is no need to send REGISTER-Requests this often.
This will generate unnecessary load on the application level.
If UDP is used for transport, empty UDP packets can be sent to keep the
NAT-binding alive.
When TCP is used, the method mentioned in RFC5626, 3.5.1 can be used to
keep the NAT-bindi
>
> A —> Switch —> B
> All 3 nodes connected with SIP connectivity.
> A sending INVITE to B but does not contain Require:100REL. Switch forwards
> Invite to B but has Require:100REL.
> B responds with 180 without SDP, Switch forwards the same to A. B then
> sends 183+SDP, which switch sends to A. T
he
media type needs to be audio, when SRTP is used.
Best Regards
Philipp Schöning
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>
> > G.722 was offered in the initial INVITE to PBX, but was not accepted
> > by PBX, in 200OK from PBX there were only G.711A
> >
> > SDP in INITIAL invite:
> > SDP PDU
> >v=0
> >o=BroadWorks 400693062 1 IN IP4 195.54.102.188
> >s=-
> >c=IN IP4 195.54.102.188
> >t=0 0
> >m
Hi Richard,
this sounds logical, but I think most SIP implementations just compare
payload type numbers, not the actual codecs used.
So payload type numbers are equated with codecs.
Best Regards
Philipp Schöning
Am Mo., 29. Okt. 2018 um 12:30 Uhr schrieb Richard Phernambucq <
r.phern
endrecv in the answer,
> the "m=" line MUST contain at least one codec the answerer is willing
> to both send and receive, from amongst those listed in the offer.
So the "m="line has to contain one payload value of the offer?!
Best Regards
Philipp Schöning
Am Mo., 29. Okt
in this case, parameters of codec 118 did not change, but only the
parameter of 8 changed.
Is this actually possible that different payload type numbers have the same
attributes?
Best Regards
Philipp Schöning
Am Mo., 29. Okt. 2018 um 08:06 Uhr schrieb Richard Phernambucq <
r.phern
r right by saying that payload description have to be
preserved during a session? It did not find this in the SDP offer/answer
RFCs.
We never saw any other vendor having issues with this signalling.
Best Regards
Philipp Schöning
___
Sip-impleme
20 matches
Mail list logo
