Jump to content

Gigaset C470IP and Call transfer via R key


penta s.r.l.
 Share

Recommended Posts

Hi,

is anyone using these phones with pbxnsip??

 

I'm able to transfer a call using "Options->External->Transfer", but it takes too much time.

I'd like to use the "R" key, but all my attempts have been futile.

 

I've also tried to do it using the "Hook flash" setup but I don't know what to enter inside the "Application Type" and "Application Signal" fields.

 

Firmware version is 021910000000 / 043.00

 

Could you help me?

 

Here below you can see a pair of screenshots of the C470IP configuration page.

 

c470ip1.jpg

c470ip2.jpg

 

Thank you.

 

--

Nicola

Link to comment
Share on other sites

Those settings seem to make sense...

 

Do you see a REFER going out to the PBX? The PBX does not perform the job of collecting the digits; this must be done by the SIP endpoint (making it also possible to edit it before sending it). Then from the PBX perspective the way of collecting the transfer information should not matter--this is a implementation detail of the endpoint user interface.

Link to comment
Share on other sites

Those settings seem to make sense...

 

Do you see a REFER going out to the PBX? The PBX does not perform the job of collecting the digits; this must be done by the SIP endpoint (making it also possible to edit it before sending it). Then from the PBX perspective the way of collecting the transfer information should not matter--this is a implementation detail of the endpoint user interface.

 

Hi,

I don't see a REFER going out.

Here it is the piece of pbxnsip's log collected when I press the R key.

You can see the INFO DTMF 16 and the DTMF R, but these info are sent to the pbx immediately, the phone does not wait for the user to compose a number.

 

Any hint?

Thank you

 

[7] 2009/10/05 10:00:31: SIP Rx udp:10.xxx.xxx.19:5060:

INFO sip:41@10.xxx.xxx.1:5060 SIP/2.0

Via: SIP/2.0/UDP 10.xxx.xxx.19:5060;branch=z9hG4bK48ab1f49244014cb3f8d9b34707cf0b;rport

From: "Francesca" <sip:41@10.xxx.xxx.1>;tag=2221630226

To: <sip:41@10.xxx.xxx.1>;tag=674e3c5180;user=phone

Call-ID: 2757463928@192_168_1_19

CSeq: 4 INFO

Contact: <sip:41@10.xxx.xxx.19:5060>

Max-Forwards: 70

User-Agent: C470IP021910000000

Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, INFO, REFER, SUBSCRIBE, NOTIFY

Content-Type: application/dtmf-relay

Content-Length: 22

 

Signal=16

Duration=86

[8] 2009/10/05 10:00:31: Received INFO DTMF 16

[9] 2009/10/05 10:00:31: Resolve 281: aaaa udp 10.xxx.xxx.19 5060

[9] 2009/10/05 10:00:31: Resolve 281: a udp 10.xxx.xxx.19 5060

[9] 2009/10/05 10:00:31: Resolve 281: udp 10.xxx.xxx.19 5060

[7] 2009/10/05 10:00:31: SIP Tx udp:10.xxx.xxx.19:5060:

SIP/2.0 200 Ok

Via: SIP/2.0/UDP 10.xxx.xxx.19:5060;branch=z9hG4bK48ab1f49244014cb3f8d9b34707cf0b;rport=5060

From: "Francesca" <sip:41@10.xxx.xxx.1>;tag=2221630226

To: <sip:41@10.xxx.xxx.1>;tag=674e3c5180;user=phone

Call-ID: 2757463928@192_168_1_19

CSeq: 4 INFO

Contact: <sip:41@10.xxx.xxx.1:5060>

User-Agent: pbxnsip-PBX/3.4.0.3201

Content-Length: 0

 

 

[6] 2009/10/05 10:00:31: Received DTMF R

[9] 2009/10/05 10:00:31: Resolve 282: aaaa udp 10.xxx.xxx.19 5060

[9] 2009/10/05 10:00:31: Resolve 282: a udp 10.xxx.xxx.19 5060

[9] 2009/10/05 10:00:31: Resolve 282: udp 10.xxx.xxx.19 5060

[9] 2009/10/05 10:00:32: Resolve 283: aaaa udp 10.xxx.xxx.20 5060

[9] 2009/10/05 10:00:32: Resolve 283: a udp 10.xxx.xxx.20 5060

[9] 2009/10/05 10:00:32: Resolve 283: udp 10.xxx.xxx.20 5060

[9] 2009/10/05 10:00:35: Resolve 284: aaaa udp 10.xxx.xxx.19 5060

[9] 2009/10/05 10:00:35: Resolve 284: a udp 10.xxx.xxx.19 5060

[9] 2009/10/05 10:00:35: Resolve 284: udp 10.xxx.xxx.19 5060

[7] 2009/10/05 10:00:35: SIP Rx udp:10.xxx.xxx.19:5060:

BYE sip:41@10.xxx.xxx.1:5060 SIP/2.0

Via: SIP/2.0/UDP 10.xxx.xxx.19:5060;branch=z9hG4bK207e79b1ac5dd431d0cdd532dec7d3b;rport

From: "Francesca" <sip:41@10.xxx.xxx.1>;tag=2221630226

To: <sip:41@10.xxx.xxx.1>;tag=674e3c5180;user=phone

Call-ID: 2757463928@192_168_1_19

CSeq: 5 BYE

Contact: <sip:41@10.xxx.xxx.19:5060>

Authorization: Digest username="41", realm="10.xxx.xxx.1", algorithm=MD5, uri="sip:41@10.xxx.xxx.1:5060", nonce="b4a9162aef36ee740423c0c11a30c07f", response="d55237bd7a3f24ae3cd92df9af807f48"

Max-Forwards: 70

User-Agent: C470IP021910000000

Content-Length: 0

 

 

[9] 2009/10/05 10:00:35: Resolve 285: aaaa udp 10.xxx.xxx.19 5060

[9] 2009/10/05 10:00:35: Resolve 285: a udp 10.xxx.xxx.19 5060

[9] 2009/10/05 10:00:35: Resolve 285: udp 10.xxx.xxx.19 5060

[7] 2009/10/05 10:00:35: SIP Tx udp:10.xxx.xxx.19:5060:

SIP/2.0 200 Ok

Via: SIP/2.0/UDP 10.xxx.xxx.19:5060;branch=z9hG4bK207e79b1ac5dd431d0cdd532dec7d3b;rport=5060

From: "Francesca" <sip:41@10.xxx.xxx.1>;tag=2221630226

To: <sip:41@10.xxx.xxx.1>;tag=674e3c5180;user=phone

Call-ID: 2757463928@192_168_1_19

CSeq: 5 BYE

Contact: <sip:41@10.xxx.xxx.1:5060>

User-Agent: pbxnsip-PBX/3.4.0.3201

RTP-RxStat: Dur=16,Pkt=811,Oct=138244,Underun=0

RTP-TxStat: Dur=16,Pkt=805,Oct=138460

Content-Length: 0

 

 

[9] 2009/10/05 10:00:45: Resolve 286: aaaa udp 10.xxx.xxx.20 5060

[9] 2009/10/05 10:00:45: Resolve 286: a udp 10.xxx.xxx.20 5060

[9] 2009/10/05 10:00:45: Resolve 286: udp 10.xxx.xxx.20 5060

[9] 2009/10/05 10:00:58: Resolve 287: aaaa udp 10.xxx.xxx.20 5060

[9] 2009/10/05 10:00:58: Resolve 287: a udp 10.xxx.xxx.20 5060

[9] 2009/10/05 10:00:58: Resolve 287: udp 10.xxx.xxx.20 5060

[9] 2009/10/05 10:00:58: Resolve 288: aaaa udp 10.xxx.xxx.19 5060

[9] 2009/10/05 10:00:58: Resolve 288: a udp 10.xxx.xxx.19 5060

[9] 2009/10/05 10:00:58: Resolve 288: udp 10.xxx.xxx.19 5060

[9] 2009/10/05 10:01:02: Resolve 289: aaaa udp 10.xxx.xxx.19 5060

[9] 2009/10/05 10:01:02: Resolve 289: a udp 10.xxx.xxx.19 5060

[9] 2009/10/05 10:01:02: Resolve 289: udp 10.xxx.xxx.19 5060

Link to comment
Share on other sites

I don't see a REFER going out.

Here it is the piece of pbxnsip's log collected when I press the R key.

You can see the INFO DTMF 16 and the DTMF R, but these info are sent to the pbx immediately, the phone does not wait for the user to compose a number.

 

Yes, that's the problem. The handset tells the PBX that some key "16" has been pressed. But the PBX does not know what to do with that... (sorry for the 200 Okay, which essentially means "got it").

 

If the handset is able to send REFER then you have to use that mode...

Link to comment
Share on other sites

Yes, that's the problem. The handset tells the PBX that some key "16" has been pressed. But the PBX does not know what to do with that... (sorry for the 200 Okay, which essentially means "got it").

 

If the handset is able to send REFER then you have to use that mode...

As you can see from the screenshots posted in the first message, there are two options related to REFER.

Not one combination of these options is working. :(

 

--

Nicola

Link to comment
Share on other sites

As you can see from the screenshots posted in the first message, there are two options related to REFER.

Not one combination of these options is working. :(

 

Hmm. If the web interfaces mentions REFER, there must be a way to get this working. Then at least the blind transfer should be easy.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...