Posted: Sat Apr 05, 2003 9:23 pm Post subject: [Asterisk-Dev] Changes to SIP
I'm not sure how many people are using the SIP stuff but I have noticed that
a few changes need to be made for asterisk to correctly work with a service
provider running Cisco proxy. I am not very familiar with SIP and basically
would like comments on these points before attempting to make modifications.
I do not wish to break it for anything else:
(o) The From header needs to be set to the account that performs the
REGISTER. I currently have a small hack that allows me to specify what the
Quote:
From header should be in the sip.conf file for that peer.
(o) When a BYE is sent the authorization digest is not sent, cisco replies
with Proxy auth required but by then Asterisk has already destroyed the
channel. From a glance it looks like the cisco phones send the same auth
digest as what was sent for the INVITE. The phone does not go through the
whole transaction of trying without auth, then receiving a proxy-auth
required error, then finally sending the auth digest.
(o) While an INVITE is "Trying" a CANCEL request sent by asterisk results
in a "487 Request Cancelled". Cisco equipment ACKs this response. It seems
that if the proxy does not receive this ACK it does not hang up the other
end until a time out period is reached. Should Asterisk be modified to not
clean up after a CANCEL and only after sending an ACK to a 487? Does
everything always send a 487 or should perhaps a channel timeout if non is
received?
(o) The ACK sent on the INVITE's 200 OK are not recognized for some reason.
This may be due to my from header hack I'm not sure. After each ACK sent the
proxy sends another 200 OK. Eventually the proxy drops the connection.
Posted: Sat Apr 05, 2003 9:45 pm Post subject: [Asterisk-Dev] Changes to SIP
Quote:
(o) The From header needs to be set to the account that performs the
REGISTER. I currently have a small hack that allows me to specify what the
>From header should be in the sip.conf file for that peer.
Can you provide an example? I believe you can use "callerid=" in the
"general" section to set the default callerid. I am not sure this is the
problem you are trying to solve though.
Quote:
(o) When a BYE is sent the authorization digest is not sent, cisco replies
with Proxy auth required but by then Asterisk has already destroyed the
channel. From a glance it looks like the cisco phones send the same auth
digest as what was sent for the INVITE. The phone does not go through the
whole transaction of trying without auth, then receiving a proxy-auth
required error, then finally sending the auth digest.
Are we permitted to send the same authorization digest as we sent on the
first call? It would still be possible for us to hang around and handle
authentication on the BYE, but this will take a little work to do. As of
CVS this morning, the SIP channel has been modified somewhat to be sure we
hang around when transmitting "final" messages until they've been ACK'd.
Quote:
(o) While an INVITE is "Trying" a CANCEL request sent by asterisk results
in a "487 Request Cancelled". Cisco equipment ACKs this response. It seems
that if the proxy does not receive this ACK it does not hang up the other
end until a time out period is reached. Should Asterisk be modified to not
clean up after a CANCEL and only after sending an ACK to a 487? Does
everything always send a 487 or should perhaps a channel timeout if non is
received?
I believe this should have been somewhat incidently fixed by CVS this
morning and is related to the above behavior. The basic problem is that
we shouldn't destroy the SIP channel until all outstanding messages have
been handled, including waiting for the 487 response to our "CANCEL" which
should be dumped just before it's destroyed.
Quote:
(o) The ACK sent on the INVITE's 200 OK are not recognized for some reason.
This may be due to my from header hack I'm not sure. After each ACK sent the
proxy sends another 200 OK. Eventually the proxy drops the connection.
I believe this is a result of improper handling of the record-route
header. Someone sent a patch that I plan to review before applying.
Please contact me off list or on IRC if the first items are not resolved
and I'll be happy to work with you on it.
Posted: Sat Apr 05, 2003 9:51 pm Post subject: [Asterisk-Dev] Changes to SIP
Quote:
I'm not sure how many people are using the SIP stuff but I have noticed
that a few changes need to be made for asterisk to correctly work with a
service provider running Cisco proxy. I am not very familiar with SIP
and basically would like comments on these points before attempting to
make modifications. I do not wish to break it for anything else:
already possible:
Posted: Sat Apr 05, 2003 10:08 pm Post subject: [Asterisk-Dev] Changes to SIP
Mark,
I would like to see the results for your discussion with james. Can you
post, once you come to a conclusion?
Gregg
On Sat, 2003-04-05 at 16:45, Mark Spencer wrote:
Quote:
> (o) The From header needs to be set to the account that performs the
> REGISTER. I currently have a small hack that allows me to specify what the
> >From header should be in the sip.conf file for that peer.
Can you provide an example? I believe you can use "callerid=" in the
"general" section to set the default callerid. I am not sure this is the
problem you are trying to solve though.
> (o) When a BYE is sent the authorization digest is not sent, cisco replies
> with Proxy auth required but by then Asterisk has already destroyed the
> channel. From a glance it looks like the cisco phones send the same auth
> digest as what was sent for the INVITE. The phone does not go through the
> whole transaction of trying without auth, then receiving a proxy-auth
> required error, then finally sending the auth digest.
Are we permitted to send the same authorization digest as we sent on the
first call? It would still be possible for us to hang around and handle
authentication on the BYE, but this will take a little work to do. As of
CVS this morning, the SIP channel has been modified somewhat to be sure we
hang around when transmitting "final" messages until they've been ACK'd.
> (o) While an INVITE is "Trying" a CANCEL request sent by asterisk results
> in a "487 Request Cancelled". Cisco equipment ACKs this response. It seems
> that if the proxy does not receive this ACK it does not hang up the other
> end until a time out period is reached. Should Asterisk be modified to not
> clean up after a CANCEL and only after sending an ACK to a 487? Does
> everything always send a 487 or should perhaps a channel timeout if non is
> received?
I believe this should have been somewhat incidently fixed by CVS this
morning and is related to the above behavior. The basic problem is that
we shouldn't destroy the SIP channel until all outstanding messages have
been handled, including waiting for the 487 response to our "CANCEL" which
should be dumped just before it's destroyed.
> (o) The ACK sent on the INVITE's 200 OK are not recognized for some reason.
> This may be due to my from header hack I'm not sure. After each ACK sent the
> proxy sends another 200 OK. Eventually the proxy drops the connection.
I believe this is a result of improper handling of the record-route
header. Someone sent a patch that I plan to review before applying.
Please contact me off list or on IRC if the first items are not resolved
and I'll be happy to work with you on it.
Posted: Sat Apr 05, 2003 10:31 pm Post subject: [Asterisk-Dev] Changes to SIP
Yes registering works fine. But as far as I understand it that is a separate
issue to an outgoing INVITE. Outgoing calls are not linked to the REGISTER.
I'm not sure how many people are using the SIP stuff but I have
noticed that a few changes need to be made for asterisk to correctly
work with a service provider running Cisco proxy. I am not very
familiar with SIP and basically would like comments on these points
before attempting to make modifications. I do not wish to break it for
anything else:
already possible:
Posted: Sat Apr 05, 2003 10:39 pm Post subject: [Asterisk-Dev] Changes to SIP
Hello Mark,
Mark Spencer wrote:
>>(o) The From header needs to be set to the account that performs the
>>REGISTER. I currently have a small hack that allows me to specify
what the
>>>From header should be in the sip.conf file for that peer.
>>
Could this be related to my SIP-481-cancel error?
The log of the cisco-router point's into this direction:
Mar 25 23:21:56: Failed FROM/TO Request check
Mar 25 23:21:56: CCSIP-SPI-CONTROL: sipSPISipIncomingMsg :
Invalid method for this state (STATE_IDLE): CANCEL
Posted: Sat Apr 05, 2003 11:01 pm Post subject: [Asterisk-Dev] Changes to SIP
Agreed.
Regards
MIKE
On Sat, 2003-04-05 at 17:08, Gregg Lebovitz wrote:
Quote:
Mark,
I would like to see the results for your discussion with james. Can you
post, once you come to a conclusion?
Gregg
On Sat, 2003-04-05 at 16:45, Mark Spencer wrote:
> > (o) The From header needs to be set to the account that performs the
> > REGISTER. I currently have a small hack that allows me to specify what the
> > >From header should be in the sip.conf file for that peer.
>
> Can you provide an example? I believe you can use "callerid=" in the
> "general" section to set the default callerid. I am not sure this is the
> problem you are trying to solve though.
>
> > (o) When a BYE is sent the authorization digest is not sent, cisco replies
> > with Proxy auth required but by then Asterisk has already destroyed the
> > channel. From a glance it looks like the cisco phones send the same auth
> > digest as what was sent for the INVITE. The phone does not go through the
> > whole transaction of trying without auth, then receiving a proxy-auth
> > required error, then finally sending the auth digest.
>
> Are we permitted to send the same authorization digest as we sent on the
> first call? It would still be possible for us to hang around and handle
> authentication on the BYE, but this will take a little work to do. As of
> CVS this morning, the SIP channel has been modified somewhat to be sure we
> hang around when transmitting "final" messages until they've been ACK'd.
>
> > (o) While an INVITE is "Trying" a CANCEL request sent by asterisk results
> > in a "487 Request Cancelled". Cisco equipment ACKs this response. It seems
> > that if the proxy does not receive this ACK it does not hang up the other
> > end until a time out period is reached. Should Asterisk be modified to not
> > clean up after a CANCEL and only after sending an ACK to a 487? Does
> > everything always send a 487 or should perhaps a channel timeout if non is
> > received?
>
> I believe this should have been somewhat incidently fixed by CVS this
> morning and is related to the above behavior. The basic problem is that
> we shouldn't destroy the SIP channel until all outstanding messages have
> been handled, including waiting for the 487 response to our "CANCEL" which
> should be dumped just before it's destroyed.
>
> > (o) The ACK sent on the INVITE's 200 OK are not recognized for some reason.
> > This may be due to my from header hack I'm not sure. After each ACK sent the
> > proxy sends another 200 OK. Eventually the proxy drops the connection.
>
> I believe this is a result of improper handling of the record-route
> header. Someone sent a patch that I plan to review before applying.
> Please contact me off list or on IRC if the first items are not resolved
> and I'll be happy to work with you on it.
>
> Mark
>
> _______________________________________________
> Asterisk-Dev mailing list
> Asterisk-Dev@lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-dev
_______________________________________________
Asterisk-Dev mailing list
Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev
--
Posted: Sat Apr 05, 2003 11:19 pm Post subject: [Asterisk-Dev] Changes to SIP
Maybe a trace would be useful.
Mark
On Sun, 6 Apr 2003, Christoph Frei wrote:
Quote:
Hello Mark,
Mark Spencer wrote:
>>(o) The From header needs to be set to the account that performs the
>>REGISTER. I currently have a small hack that allows me to specify
what the
>>>From header should be in the sip.conf file for that peer.
>>
Could this be related to my SIP-481-cancel error?
The log of the cisco-router point's into this direction:
Mar 25 23:21:56: Failed FROM/TO Request check
Mar 25 23:21:56: CCSIP-SPI-CONTROL: sipSPISipIncomingMsg :
Invalid method for this state (STATE_IDLE): CANCEL
Posted: Sat Apr 05, 2003 11:44 pm Post subject: [Asterisk-Dev] Changes to SIP
This is a multi-part message in MIME format.
--------------050709090503060903070406
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Hi Mark,
here. One log with cancel, one without.
Greetings,
Christoph
Mark Spencer wrote:
>Maybe a trace would be useful.
>
>Mark
>
>On Sun, 6 Apr 2003, Christoph Frei wrote:
>
>>Hello Mark,
>>
>>Mark Spencer wrote:
>>
>> >>(o) The From header needs to be set to the account that performs the
>> >>REGISTER. I currently have a small hack that allows me to specify
>>what the
>> >>>From header should be in the sip.conf file for that peer.
>> >>
>>Could this be related to my SIP-481-cancel error?
>>
>>The log of the cisco-router point's into this direction:
>>
>>Mar 25 23:21:56: Failed FROM/TO Request check
>>Mar 25 23:21:56: CCSIP-SPI-CONTROL: sipSPISipIncomingMsg :
>>Invalid method for this state (STATE_IDLE): CANCEL
>>
>>
Mar 25 23:21:43: HandleUdpSocketReads :Msg enqueued for SPI with IPaddr: 192.168.1.1:5060
Mar 25 23:21:43: CCSIP-SPI-CONTROL: sipSPISipIncomingMsg
Mar 25 23:21:43: 0x62DF2EC8 : State change from (UNDEFINED, SUBSTATE_NONE) to (STATE_IDLE, SUBSTATE_NONE)
Mar 25 23:21:43: CCSIP-SPI-CONTROL: act_idle_new_message
Mar 25 23:21:43: CCSIP-SPI-CONTROL: Clock Time Zone is UTC, same as GMT: Using GMT
Mar 25 23:21:43: sip_stats_method
Mar 25 23:21:43: CCSIP-SPI-CONTROL: sact_idle_new_message_invite
Mar 25 23:21:43: CCSIP-SPI-CONTROL: sipSPIUASSessionTimer
Mar 25 23:21:43: sipSPIGetSdpBody : Parse incoming session description
Mar 25 23:21:43: ****Adding to UAS Request table
Mar 25 23:21:43: CCSIP-SPI-CONTROL: sipSPIMatchSrcIpGroup
Mar 25 23:21:43: CCSIP-SPI-CONTROL: sipSPIMatchSrcIpGroup: Match not found on carrier id
Mar 25 23:21:43: CCSIP-SPI-CONTROL: sipSPIMatchSrcIpGroup: Match not found on Incoming called number: 0791234567
Mar 25 23:21:43: CCSIP-SPI-CONTROL: sipSPIMatchSrcIpGroup: Match not found on destination pattern: 501
Mar 25 23:21:43: CCSIP-SPI-CONTROL: sipSPIContinueNewMsgInvite
Mar 25 23:21:43: Received ;screen= ;privacy= -> Setting Octet3A=0x80
Mar 25 23:21:43: sipSPIContinueNewMsgInvite: non dial peer leg - using RTP Supported Codecs
Mar 25 23:21:43: sipSPIContinueNewMsgInvite: RTP Preferred Codecs supported by GW 18
Mar 25 23:21:43: sipSPIContinueNewMsgInvite: RTP Preferred Codecs supported by GW 0
Mar 25 23:21:43: sipSPIContinueNewMsgInvite: RTP Preferred Codecs supported by GW 8
Mar 25 23:21:43: sipSPIContinueNewMsgInvite: RTP Preferred Codecs supported by GW 4
Mar 25 23:21:43: sipSPIContinueNewMsgInvite: RTP Preferred Codecs supported by GW 2
Mar 25 23:21:43: sipSPIContinueNewMsgInvite: RTP Preferred Codecs supported by GW 15
Mar 25 23:21:43: sipSPIContinueNewMsgInvite: RTP Preferred Codecs supported by GW 3
Mar 25 23:21:43: sipSPIDoFaxMediaNegotiation()
Mar 25 23:21:43: sipSPIDoMediaNegotiation: Codec (gsmfr) Negotiation Successful on Static Payload
Mar 25 23:21:43: sipSPIDoPtimeNegotiation: No ptime present or multiple ptime attributes that can't be handled
Mar 25 23:21:43: sipSPIGetSDPDirectionAttribute: No direction attribute present or multiple direction attributes that can't be handled
Mar 25 23:21:43: sipSPIDoDTMFRelayNegotiation: Requested DTMF-RELAY option(s) not found in Preferred DTMF-RELAY option list!
Mar 25 23:21:43: sipSPIDoMediaNegotiation: DTMF Relay mode : Inband Voice
Mar 25 23:21:43: sip_sdp_get_modem_relay_cap_params:
Mar 25 23:21:43: sip_sdp_get_modem_relay_cap_params: NSE payload from X-cap = 0
Mar 25 23:21:43: sip_do_nse_negotiation: SDP not present. Use local NSE payload 100.
Mar 25 23:21:43: sip_select_modem_relay_params: X-tmr not present in SDP. Disable modem relay
Mar 25 23:21:43: sipSPIUpdCcbWithSdpInfo: SDP Media Information:
Negotiated Codec : gsmfr , bytes :33
Early Media : 0
Delayed Media : 0
Bridge Done : 0
New Media : 0
DSP DNLD Reqd : 0
Media Dest addr/Port : 192.168.1.1:23960
Orig Media Addr/Port : 0.0.0.0:0
Mar 25 23:21:43: sipSPIDoQoSNegotiation - SDP body with media description
Mar 25 23:21:43: sipSPIAddBillingInfoToCcb: sipCallId for billing records = 2b1c469a5bd268e53e1d8e8579ffbba4@192.168.1.1
Mar 25 23:21:43: adding call id 292 to table
Mar 25 23:21:43: Queued event from SIP SPI : SIPSPI_EV_SEND_MESSAGE (7)
Mar 25 23:21:43: sip_stats_status_code
Mar 25 23:21:43: ****Adding to UAS Response table
Mar 25 23:21:43: Previous Hop 192.168.1.1:5060
Mar 25 23:21:43: 0x62DF2EC8 : State change from (STATE_IDLE, SUBSTATE_NONE) to (STATE_RECD_INVITE, SUBSTATE_NONE)
Mar 25 23:21:43: Sent:
SIP/2.0 100 Trying
Mar 25 23:21:43: Queued event from SIP SPI : SIPSPI_EV_CC_CALL_PROCEEDING (11)
Mar 25 23:21:43: ccsip_report_digit_control: enable=0:
Mar 25 23:21:43: ccsip_report_digit_control: disabled.
Mar 25 23:21:43: CCSIP-SPI-CONTROL: act_recdinvite_proceeding
Mar 25 23:21:43: %ISDN-6-LAYER2UP: Layer 2 for Interface BR1/0, TEI 107 changed to up
Mar 25 23:21:47: Queued event from SIP SPI : SIPSPI_EV_CC_CALL_ALERTING (13)
Mar 25 23:21:47: CCSIP-SPI-CONTROL: sipSPIIncomingCallSDP
Mar 25 23:21:47: sipSPIUpdateSrcSdpFixedPart
Mar 25 23:21:47: sipSPIUpdateSrcSdpVariablePart
Mar 25 23:21:47: sipSPIRtcpUpdates: rtcp_session info
laddr = 192.168.1.2, lport = 18648, raddr = 192.168.1.1, rport=23960
Mar 25 23:21:47: sipSPIRtcpUpdates:NO extraction of source address from remote media
Mar 25 23:21:47: sipSPIRtcpUpdates No rtp session in bridge, create a new one
Mar 25 23:21:47: CCSIP-SPI-CONTROL: ccsip_caps_ind
Mar 25 23:21:47: ccsip_get_rtcp_session_parameters: CURRENT VALUES:
ccCallID=658, current_seq_num=0x150D
Mar 25 23:21:47: ccsip_get_rtcp_session_parameters: NEW VALUES:
ccCallID=658, current_seq_num=0x9CD
Mar 25 23:21:47: ccsip_caps_ind: Load DSP with negotiated codec : gsmfr, Bytes=33
Mar 25 23:21:47: sipSPISetDTMFRelayMode: set DSP for dtmf-relay = CC_CAP_DTMF_RELAY_INBAND_VOICE_AND_OOB
Mar 25 23:21:47: sip_set_modem_caps: Negotiation already Done. Set negotiated Modem caps
Mar 25 23:21:47: sip_set_modem_caps: Modem Relay & Passthru both disabled
Mar 25 23:21:47: sip_set_modem_caps: nse payload = 100, ptru mode = 0, ptru-codec=0, redundancy=0, xid=0, relay=0, sprt-retry=12, latecncy=200, compres-dir=3, dict=1024, strnlen=32
Mar 25 23:21:47: ccsip_caps_ind: Load DSP with codec : gsmfr, Bytes=33
Mar 25 23:21:47: CCSIP-SPI-CONTROL: ccsip_caps_ack
Mar 25 23:21:47: CCSIP-SPI-CONTROL: act_recdinvite_alerting
Mar 25 23:21:47: Session Type is Media/Qos/Security, SDP body is attached
Mar 25 23:21:47: CCSIP-SPI-CONTROL: sipSPIIncomingCallSDP
Mar 25 23:21:47: SDP already there use old sdp and updatemedia if needed
Mar 25 23:21:47: sipSPIUpdateSrcSdpVariablePart
Mar 25 23:21:47: sip_generate_sdp_xcaps_list: Modem Relay and T38 disabled. X-cap not needed
Mar 25 23:21:47: Queued event from SIP SPI : SIPSPI_EV_SEND_MESSAGE (7)
Mar 25 23:21:47: sip_stats_status_code
Mar 25 23:21:47: 0x62DF2EC8 : State change from (STATE_RECD_INVITE, SUBSTATE_NONE) to (STATE_RECD_INVITE, SUBSTATE_RECD_INVITE_RECD_PROGRESS)
Mar 25 23:21:47: Sent:
SIP/2.0 183 Session Progress
Mar 25 23:21:56: HandleUdpSocketReads :Msg enqueued for SPI with IPaddr: 192.168.1.1:5060
Mar 25 23:21:56: *****CCB found in UAS Request table
Mar 25 23:21:56: Failed FROM/TO Request check
Mar 25 23:21:56: CCSIP-SPI-CONTROL: sipSPISipIncomingMsg
Mar 25 23:21:56: CCSIP-SPI-CONTROL: sipSPISipIncomingMsg : Invalid method for this state (STATE_IDLE): CANCEL
Mar 25 23:21:56: CCSIP-SPI-CONTROL: sipSPISendErrorRespNoCCB
Mar 25 23:21:56: Queued event from SIP SPI : SIPSPI_EV_SEND_MESSAGE (7)
Mar 25 23:21:56: sip_stats_status_code
Mar 25 23:21:56: Sent:
SIP/2.0 481 Call Leg/Transaction Does Not Exist
Mar 25 23:21:56: HandleUdpSocketReads :Msg enqueued for SPI with IPaddr: 192.168.1.1:5060
Mar 25 23:21:56: *****CCB found in UAS Request table
Mar 25 23:21:56: Failed FROM/TO Request check
Mar 25 23:21:56: CCSIP-SPI-CONTROL: sipSPISipIncomingMsg
Mar 25 23:21:56: CCSIP-SPI-CONTROL: sipSPISipIncomingMsg : Invalid method for this state (STATE_IDLE): ACK
voicegate#
voicegate#
voicegate#
voicegate#
voicegate#
voicegate#
Mar 25 23:22:08: Queued event from SIP SPI : SIPSPI_EV_CC_CALL_DISC_PROG_IND (23)
Mar 25 23:22:08: CCSIP-SPI-CONTROL: act_recdinvite_progress
voicegate#sh version
Cisco Internetwork Operating System Software
IOS (tm) 3600 Software (C3620-IS-M), Version 12.2(13)T1, RELEASE SOFTWARE (fc1)
TAC Support: http://www.cisco.com/tac
Copyright (c) 1986-2003 by cisco Systems, Inc.
Compiled Fri 03-Jan-03 19:45 by ccai
Image text-base: 0x6000891C, data-base: 0x6184C000
ROM: System Bootstrap, Version 11.1(19)AA, EARLY DEPLOYMENT RELEASE SOFTWARE (fc1)
voicegate uptime is 4 weeks, 2 days, 1 hour, 30 minutes
System returned to ROM by reload
System restarted at 21:52:20 UTC Sun Feb 23 2003
System image file is "flash:c3620-is-mz.122-13.T1.bin"
cisco 3620 (R4700) processor (revision 0x81) with 61440K/4096K bytes of memory.
Processor board ID 12406665
R4700 CPU at 80Mhz, Implementation 33, Rev 1.0
Bridging software.
X.25 software, Version 3.0.0.
Basic Rate ISDN software, Version 1.1.
1 Ethernet/IEEE 802.3 interface(s)
1 ISDN Basic Rate interface(s)
--More-- 2 Voice TE BRI interface(s)
DRAM configuration is 32 bits wide with parity disabled.
29K bytes of non-volatile configuration memory.
16384K bytes of processor board System flash (Read/Write)
8192K bytes of processor board PCMCIA Slot0 flash (Read/Write)
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum